\pard\tx520\tx1060\tx1600\tx2120\tx2660\tx3200\tx3720\tx4260\tx4800\tx5320\f0\b0\i0\ulnone\fs28\fc0\cf0 Q: I have libraries compiled for NeXT 3.0 machines that I need to use on NEXTSTEP for Intel Processors. What should I do to make them work?\
\
Q: I wrote an application under 3.1 on an Intel NEXTSTEP platform that uses a library I wrote under 3.0, but it won't link properly—why?\
\
Q: How do I make my 3.0 libraries accessible in a multi-architecture form to 3.1 applications?\
\
A: Libraries that were compiled under NEXTSTEP 3.0 and earlier should work fine under 3.1—for NeXT hardware. Some extra work is required to make them work properly under NEXTSTEP 3.1 for Intel Processors. Because the m68k architecture and the i386 architectures are radically different, it is necessary for NEXTSTEP to have access to a binary for both architectures in order to provide an executable that runs on both machines. Libraries, being binary files containing machine instructions, are no different from any application in this respect. Building multi-architecture applications is easy, since the
\b Project Builder
\b0 application takes care of the details of building Multi-Architecture Binary files (MAB files) when requested. But
\b Project Builder
\b0 doesn't manage libraries, so an application that you have compiled may fail to link properly because of the lack of a library matching the architecture type of the machine you are compiling for.\
\
3.1 provides a new utility,
\b libtool
\b0 , for generating multi-architecture (or "fat") libraries.
\b libtool
\b0 is intended to replace both the
\b ar
\b0 and
\b ranlib
\b0 utilities. Traditionally, the construction of a library is managed by a
\b Makefile
\b0 , which usually does roughly the following:\
\
\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fi-980\li980\fc0\cf0 1) Compiles the .c and .m (source) files into .o (object) files, using the compiler (
\b cc
\b0 ).\
2) Archives the resulting .o files into a .a (library) file, using the archiver (
\b ar
\b0 ).\
3) Generates a table of contents file in the archive, using the
\b0 , with the r, u, and v switches on, has been replaced with a call to
\b libtool
\b0 , and that calling
\b ranlib
\b0 is no longer necessary. The r, u, and v switches allowed
\b ar
\b0 to update only the objects that were newer than the ones in the archive; the
\b libtool
\b0 call doesn't have this capability, but is much faster than
\b ar
\b0 , and in addition, it is capable of archiving fat objects, which
\b ar
\b0 cannot do.\
\
So where do multiple-architecture objects come in? So-called "fat" objects are generated when the compiler is told to generate objects of more than one architecture type, using the
\b -arch
\b0 flag. If you look at the compile text field in Project Builder, you should notice that it uses this flag whenever it is asked to generate something for both the m68k and i386 architectures. The change needed to the above sequence is:\
\f0\fs28 And that's all there is to it. The gains to library-building using
\b libtool
\b0 are the ability to make fat libraries, and the elimination of the need to use
\b ranlib
\b0 . The loss is the ability to update only those files in the archive that have timestamps older than the input files—in general, the amount of time lost in moving from
\b ar
\b0 and
\b ranlib
\b0 to
\b libtool
\b0 should be minimal, if any.\
\
For the Makefile minded, here's a simple example of what needs to be changed. The first file is the original, which compiles into a single-architecture library, and the second file will generate the multi-architecture library:\
